home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / comunic / hcom_108.zip / README.108 < prev   
Text File  |  1993-09-04  |  6KB  |  126 lines
  1.  
  2.         HydraCom 1.08 public beta - 4 September 1993
  3.  
  4.   NOTE: This is just an update to the 1.00/1.03 MS-DOS executables.
  5.   The docs and other files are the same as in the 1.00 archive.
  6.   The most important changes and additions are listed in this file.
  7.  
  8.   If you're still running version 1.00, definitly read the section
  9.   preceded by '!' at the start of the line, otherwise your existing
  10.   installation may not work!!
  11.  
  12.  
  13.   One thing I want is updated and new info for installing HydraCom
  14.   in terminal and BBS software, to put in HYDRACOM.DOC
  15.   Some people have sent me some config info, but never complete.
  16.   As I don't have all that software, I can't write the story!
  17.   You really need to provide complete paragraphs about your software,
  18.   which I can just put straight into my documentation.
  19.   COMPLETE info for RAFM, PC-Board, SuperBBS, TAG BBS, Terminate, etc.
  20.   PLEASE HELP!
  21.  
  22.  
  23.   So, now to the actual list of changes 1.00 -> 1.03:
  24.  
  25. ! * DSZ logfile fixed, and DSZLOG environment variable correctly processed.
  26. !   You will need to change your setup if you use for instance Maximus or
  27. !   RAFM, otherwise your software will not know what happened.....
  28. !   The letters for receive and transmit respectively were R and H.
  29. !   They are now H and h, ie. H=Upload(get/receive), h=download(send/transmit).
  30.   * HydraCom will now always exit with errorlevel 1 if the carrier was dropped
  31.     or the session was aborted. In 1.00, this depended on the situation....
  32.   * Option addition for Dutchie service requests - you won't notice.
  33.   * Data block sizes step-up after error-recovery now improved; it was kinda
  34.     limited and also fixed; it's now more dynamic, depending on linespeed.
  35.   * Duplicate device (chat) packets now ACKed better.
  36.     Could create a misunderstanding between two sides.
  37.   * Chat continuing after end of batch is now slightly faster in correcting
  38.     (resending) a bad packet.
  39.   * CRC-16/32 routines for MS-DOS executable now in very fast assembler.
  40.     Don't worry, the source contains their 100% compatible C equivalents too!
  41.     In practise, this won't make any difference for you. Hydra was already fast
  42.     enough to handle VERY high speed links....
  43.   * Terminal Upload-queue string entry didn't allow ASCII 128-255.
  44.     Changed, upon a request from Sweden. They use characters in that range...
  45.   * Files now opened in shared DENY_NONE instead of DENY_WRITE.
  46.     I don't like it, but it's compatible with for instance DSZ, and so
  47.     otherwise causes trouble on multiline systems with multiple users
  48.     downloading the same file simultanously. Only the first could open....
  49.   * In HydraCfg the 'loglevel' bug was fixed; now correctly writes 'level'.
  50.  
  51.  
  52.   Changed 1.03 -> 1.08
  53.  
  54.   Quite many actually, as you will notice when running either HydraCom or
  55.   HydraCfg.
  56.   * Most importantly HydraCom now has its own brandnew async routines.
  57.     The old ones were really bad and just failed miserably on many systems,
  58.     so I finally decided to write my own.
  59.     Even if you have a FOSSIL driver loaded, try disabling HydraCom's use
  60.     of FOSSIL to test the internal routins - please? ('nofossil' option)
  61.   * VideoFOSSIL support disabled. My own windowing library could use VFOSSIL
  62.     if present, but it used some routines which are NOT used by Binkley, and
  63.     in Bob Hartman's VFOS_IBM these specific functions are buggy causing the
  64.     system to crash. There was a warning about using a fixed VFOS_IBM, but
  65.     it caused too much trouble anyway.
  66.     For compatibility with lesser clones, you CAN now select BIOS video.
  67.   * A number of options was added to deal with specific situations.
  68.   * Like I said, much more.... just use and enjoy!
  69.  
  70.  
  71.   People having trouble with missing characters (receive or transmit errors):
  72.  
  73.   Disable FOSSIL ('nofossil' option) and try the internal async routines.
  74.   Amazing as it may sound, this solves a lot of problems and even works very
  75.   well under MultiTaskers such as DESQview.
  76.  
  77.   If you have a high speed modem, make sure the FOSSIL is LOCKED.
  78.   ALWAYS set the FOSSIL's transmit and receive buffers to 4086 bytes each.
  79.   Also, make sure you enable RTS/CTS (hardware) flow control in both HydraCom
  80.   and your modem.
  81.  
  82.   With high speed modems, a 16550A UART is always highly recommended.
  83.   If you see 16550 instead of 16550A (note the missing A) reported in
  84.   HydraCfg's 'Port Assignment' screen, you have a FAULTY UART and you should
  85.   get a replacement. On this particular type the FIFOs did not work.
  86.   When using the internal async routines, you can adjust the receiver FIFO
  87.   trigger level. If you are getting errors when receiving files, try lowering
  88.   this value. Don't ever switch off the FIFO though!
  89.  
  90.   If you have disk caching software which uses staged write like HyperDisk,
  91.   try switching off that option. On some systems it works with staged write,
  92.   on others it doesn't.... so there is no general on/off rule.
  93.   Also try enabling the 'slowdisk' option. This feature will only work if
  94.   you are using either the internal async routines or the X00 FOSSIL driver
  95.   version 1.24 or higher. BNU currently does not support the extended FOSSIL
  96.   functions required to do this.
  97.  
  98.   Make sure handshaking is set correctly in your modem.
  99.   Some are set to 'CTS follows RTS'; this is INCORRECT.
  100.   RTS is used by the computer to signal to the modem to stop incoming data (if
  101.   the FOSSIL receive buffer is almost full), and CTS is used by the modem to
  102.   tell the computer to stop sending data (when the modem's transmit buffer is
  103.   almost full).
  104.   The terminology in the documentation, and HAYES commands or registers differ
  105.   per modem brand and type, so just read carefully, and perhaps ask advice from
  106.   an experienced modem user.
  107.  
  108.  
  109.   If you have any problems, don't blame HydraCom by saying 'but other protocol
  110.   drivers work fine here'.... The Hydra protocol is different, and for instance
  111.   moves more filedata per second than other protocols, even bidirectional ones.
  112.   Problems are usually caused by some kind of faulty installation or setup,
  113.   for instance a modem setting that doesn't affect other protocols....
  114.   Don't just drop HydraCom, keep trying and ask for help. It's worth it!
  115.  
  116.  
  117.   Please report back as soon as possible if you have any comments?
  118.  
  119.   Arjen Lentz
  120.   AINEX-BBS +31-33-633916
  121.   FidoNet 2:283/512
  122.   arjen_lentz@f512.n283.z2.fidonet.org
  123.  
  124.  
  125.   --- end of "readme.108" ---
  126.